-
Notifications
You must be signed in to change notification settings - Fork 379
Add workflow for rolling back release #3033
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
f4f6c63
to
3376c74
Compare
…ges are available
7c91b1c
to
67e42fe
Compare
|
||
uses: ./.github/workflows/prepare-release.yml | ||
|
||
rollback: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll soon be needing to release CodeQL Action v4 to run on Node 24. I think the backport automation in update-release-branch.yml
would create necessary backport releases, but I think we might want a way to more quickly rollback a change across all active release branches (without waiting for the full set of PR checks). Perhaps it makes sense to matrix this job across all active release branches?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd propose doing this in a follow-up PR once we have the basic version of this workflow working.
run: | | ||
git push origin --atomic --force refs/tags/"${RELEASE_TAG}" refs/tags/"${MAJOR_VERSION_TAG}" | ||
|
||
- name: Prepare partial Changelog |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could be clearer what we mean here by "partial changelog". It's still not fully clear, but we could call it "release description" for instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used the existing terminology for this from the release workflow. Happy to change this to something else here, but we should probably update it there then as well to be consistent.
run: | | ||
# Do not mark this release as latest. The most recent CLI release must be marked as latest. | ||
# Set as a draft to give us an opportunity to review the rollback release. | ||
gh release create \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this print a link to the new release? It might be nice to add a link to the job summary to make it easier to move forwards to the next step of reviewing and publishing the release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it automatically does that, but I have pushed a change which computes the release URL and adds it to the job summary.
on: | ||
# You can trigger this workflow via workflow dispatch to start a rollback. | ||
# This will create a draft release that mirrors the release for `rollback-tag`. | ||
workflow_dispatch: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is intended to be triggered on main
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's the intention. I think it could probably work if triggered from a different branch, but I haven't verified that.
uses: ./.github/actions/prepare-mergeback-branch | ||
with: | ||
base: "main" | ||
head: "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this blank?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The prepare-mergeback-branch
action only uses it as part of the mergeback PR title, where it is typically something like refs/heads/releases/v3
. That didn't make sense here, because we are not touching the v3
branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.
Co-authored-by: Henry Mercer <henrymercer@github.com>
This PR adds a new workflow that can be manually triggered to create a rollback release. I.e. the workflow creates a new release which mirrors an older, previous release. Since we publish immutable releases, this is necessary to "revert" a broken release.
The process is:
main
. (For testing on a PR only: we checkout the repository at the PR head instead.)rollback_changelog.py
script. There is some duplication among the Python scripts that could be neater, but I didn't want to tackle big improvements there as part of this PR.prepare_changelog.py
script.package.json
changes targetingmain
. (For testing on a PR only: we skip creating the PR, but still push the branch.)Once the process has completed:
This is best reviewed commit-by-commit.
Risk assessment
For internal use only. Please select the risk level of this change:
Merge / deployment checklist